home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / MacApp Documentation / MacApp AppleLink Messages / MacApp.Tech$ Jun 89 / V0057-Re TDocument rethin-Jun89 < prev    next >
Encoding:
Text File  |  1989-06-26  |  2.7 KB  |  70 lines  |  [TEXT/GEOL]
  1. Item    0095333                         20-June-89        19:27
  2.  
  3. From:   ROSENSTEIN1                     Rosenstein, Larry
  4.  
  5. To:     D2086                           Efficient Field Svc, C Faith, PRT
  6.  
  7. cc:     MACAPP.TECH$                    MACAPP Tech
  8.  
  9. Sub:    re TDocument rethink
  10.  
  11. Curtis,
  12.  
  13. I agree with the suggestion that TDocument's technique of saving files (by
  14. creating a temporary copy, deleting the original, and renaming the new file)
  15. should be factored out into a TFile (or some such) class.
  16.  
  17. This would serve 2 purposes.  (1) Whenever the application needed to save a
  18. file, it could do so with an instance of TFile.  It wouldn't be necessary to
  19. have an instance of TDocument to do this.  (2) It would help people to build up
  20. libraries of classes that implement specific document formats (e.g.
  21. TMacPaintFile, TPICTFile, etc.)  This would make it easier for applications to
  22. support different file types.
  23.  
  24. This would make it easier to save several files to assciated with one document
  25. object.
  26.  
  27. I think TDocument does in fact map to as many situations as possible.  So far,
  28. I can recall only accounting and database programs where people claim that
  29. TDocument does not satisfy their needs, and even in those cases, I think I
  30. could associate a document object with some concept in the application (a
  31. company's information and the database, respectively).
  32.  
  33. I think the problem you raise is because the Macintosh document model is too
  34. close to that of the file system.  The Finder really has no concept of a
  35. document, it only deals with files.
  36.  
  37.  
  38. Regarding your specific suggestions for MacApp 2.1:
  39.  
  40. (1) The reason closing a window sets gTarget to gApplication is that when the
  41. next window gets activated it has a chance to set the target to whatever it
  42. wants.  What would you propose setting gTarget to?
  43.  
  44. It is true that MacApp should not make any assumptions about the sequence of
  45. objects in the chain.  Perhaps TWindow should contain an field fInactiveTarget,
  46. which would complement the field fTarget, and could be used in this case.
  47.  
  48.  
  49. (2) I don't think complicating the command handling chain is the answer.  The
  50. structure of the command handling chain is directly visible to the user, in the
  51. sense that it determines whether a particular command is enabled, and how the
  52. command is executed.  Complicating the event handler chain inside of MacApp
  53. will likely complicate the user interface to the program.
  54.  
  55. I think it is the application's job to know about all its documents, just as
  56. the document knows about all its windows.
  57.  
  58. It wouldn't be very hard to change MacApp to support having a document with no
  59. visible windows.  But I also think that this has user interface implications
  60. and shouldn't be done without more thought.
  61.  
  62. Larry Rosenstein
  63.  
  64.  
  65.  
  66.  
  67.  
  68.  
  69.  
  70.